Watermarking screen capture content

ABSTRACT

Information is displayed on a device by writing data to a buffer in memory, the content of the buffer describing a screen display of the device at a particular point in time. A watermarked version of the buffer content is generated by watermarking the content of the buffer with data, such as data identifying a user of the device and/or a copy of a program (e.g., an operating system) running on the device. The watermarked version of the buffer content is then made available, such as in response to a screen capture request. The data embedded in the watermarked version of the content is undetectable (or nearly undetectable) to the human eye, but can nonetheless be extracted by other computing devices or data extraction systems.

BACKGROUND

As computing technology has advanced, computer programs have becomeincreasingly complex, resulting in programs that take a large amount oftime to build and test. This increased complexity has resulted inprograms that provide significant functionality and usability, but thedevelopment of these programs is not without its problems. One suchproblem is that a large number of people can be involved in thedevelopment of these programs, including people employed by the programdeveloper as well as third parties. While these people are typicallyrequired to keep information about these programs confidential,information about these programs can sometimes be intentionally orinadvertently released. When such information is released, it isdesirable to know who released the information so that appropriateremedial action can be taken (e.g., in order to prevent futurereleases). Unfortunately, when information regarding a program isreleased, it is oftentimes difficult to determine who released theinformation, making it difficult to take any remedial action.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

In accordance with one or more aspects, a content of a graphics bufferof a computing device is obtained. This content of the graphics bufferdescribes a screen display at a particular time. The content of thegraphics buffer is watermarked with data identifying one or both of auser of the computing device and a copy of a program running on thecomputing device, and the watermarked content of the graphics buffer isstored or otherwise made available (e.g., in response to a screencapture request).

BRIEF DESCRIPTION OF THE DRAWINGS

The same numbers are used throughout the drawings to reference likefeatures.

FIG. 1 is a block diagram illustrating an example computing deviceimplementing the watermarking screen capture content in accordance withone or more embodiments.

FIG. 2 illustrates an example screen capture watermarking system inaccordance with one or more embodiments.

FIG. 3 illustrates another example screen capture watermarking system inaccordance with one or more embodiments.

FIG. 4 is a block diagram illustrating an example watermark dataextraction system in accordance with one or more embodiments.

FIG. 5 is a flowchart illustrating an example process for watermarkingscreen capture content in accordance with one or more embodiments.

FIG. 6 is a flowchart illustrating another example process forwatermarking screen capture content in accordance with one or moreembodiments.

FIG. 7 illustrates an example system that includes an example computingdevice that is representative of one or more systems and/or devices thatmay implement the various techniques described herein.

DETAILED DESCRIPTION

Watermarking screen capture content is discussed herein. Information isdisplayed on a device by writing data to a buffer in memory, the contentof the buffer describing a screen display of the device at a particularpoint in time. The content of the buffer is updated as the informationto be displayed changes, and the device updates the screen display basedon the content of the buffer at a particular interval (e.g., 30 timesper second). A watermarked version of the buffer content is generated bywatermarking the content of the buffer with various data, such as dataidentifying a copy of a program (e.g., an operating system) running onthe device and/or a user of the device. The watermarked version of thebuffer content is then made available, such as in response to a screencapture request. The data embedded in the watermarked version of thecontent is undetectable (or nearly undetectable) to the human eye, butcan nonetheless be extracted by other computing devices or dataextraction systems.

FIG. 1 is a block diagram illustrating an example computing device 100implementing the watermarking screen capture content in accordance withone or more embodiments. Computing device 100 can be a variety ofdifferent types of devices, such as a physical device or a virtualdevice. For example, computing device 100 can be a physical device suchas a desktop computer, a server computer, a laptop or netbook computer,a tablet or notepad computer, a mobile station, an entertainmentappliance, a set-top box communicatively coupled to a display device, atelevision or other display device, a cellular or other wireless phone,a game console, an automotive computer, and so forth. Computing device100 can also be a virtual device, such as a virtual machine running on aphysical device. A virtual machine can be run on any of a variety ofdifferent types of physical devices (e.g., any of the various typeslisted above). Thus, computing device 100 may range from full resourcedevices with substantial memory and processor resources (e.g., personalcomputers, game consoles) to low-resource devices with limited memoryand/or processing resources (e.g., traditional set-top boxes, hand-heldgame consoles).

Computing device 100 includes a user input module 102, a buffer 104, oneor more programs 106, and a screen capture watermarking system 108. Userinput module 102 receives user inputs from a user of computing device100. User inputs can be provided in a variety of different manners, suchas by pressing one or more keys of a keypad or keyboard of device 100,pressing one or more keys of a controller (e.g., remote control device,mouse, track pad, etc.) of device 100, pressing a particular portion ofa touchpad or touchscreen of device 100, making a particular gesture ona touchpad or touchscreen of device 100, and/or making a particulargesture on a controller (e.g., remote control device, mouse, track pad,etc.) of device 100. User inputs can also be provided via other physicalfeedback input to device 100, such as tapping any portion of device 100,an action that can be recognized by a motion detection or othercomponent of device 100 (such as shaking device 100, rotating device100, bending or flexing device 100, etc.), and so forth. User inputs canalso be provided in other manners, such as via voice or other audibleinputs to a microphone, via motions of hands or other body partsobserved by an image capture device, and so forth.

Programs 106 are various software and/or firmware programs that can berun on computing device 100. Each program 106 can be any set ofinstructions that can be executed, installed, interpreted, or otherwiserun on computing device 100. Programs 106 can include programs installedon computing device 100, programs copied to and run on computing device100 without installation, script programs run on computing device 100,and so forth. Programs 106 can include an operating system of device 100and/or other applications run by an operating system or otherapplication of device 100.

Buffer 104 is memory the content of which describes a screen displaythat is to be displayed by the device (e.g., on a screen of the device)at a particular time. Buffer 104 is also referred to as graphics memoryor a graphics buffer, and can be changed at various intervals to reflectchanges in the information to be displayed. One or more programs 106 canalter the data stored in buffer 104 at various times to reflect theinformation that the one or more programs 106 desire to have displayedto a user of computing device 100. The data in buffer 104 is used by agraphics system (e.g., of computing device 100) to generate a screendisplay for device 100, which is the image or information displayed bydevice 100. The graphics system can generate a screen display at variousintervals (e.g., 30 times per second, in response to a change in thedata in buffer 104, and so forth). Computing device 100 can include oneor more components (e.g., displays, projectors, etc.) on which data isdisplayed by device 100, or alternatively device 100 can generate one ormore signals that are output to other devices or components (e.g., otherdevices including displays, projectors, etc.) that are separate fromcomputing device 100.

In one or more embodiments, buffer 104 can be a screen buffer. Programs106 write, to the screen buffer, the data describing the informationthat the programs 106 desire to have displayed to a user of computingdevice 100. A graphics system (which may be included at least in part inan operating system of computing device 100, which can be a program 106)generates information to include in a frame buffer based on the contentof the screen buffer. The frame buffer identifies color values for everypixel of a display, and the graphics system uses the frame buffer togenerate the screen display at a particular point in time.Alternatively, buffer 104 can be other buffers in computing device 100.For example, buffer 104 can be a frame buffer.

Screen capture watermarking system 108 includes a screen capture module112 and a watermarking module 114. Although screen capture watermarkingsystem 108 is illustrated as separate from program 106, at least part ofsystem 108 can alternatively be included as part of a program 106 (e.g.,be included as part of an operating system of device 100).

Screen capture module 112 manages screen capture functionality of device100. In response to a screen capture request, screen capture module 112obtains the content of buffer 104. The obtaining the content of buffer104 is also referred to as a screen capture. A screen capture request isa request for an image of the current screen display (typically thescreen display when the request is received). Any of a variety of userinputs as discussed above can be used to input a screen capture request,such as pressing a “print screen” key of a keyboard, selecting aparticular hot key sequence, selecting a menu item, entering aparticular gesture on a touchscreen, providing a voice command, and soforth. The content of buffer 104 is the data stored in buffer 104.

Watermarking module 114 manages watermarking functionality of device100. Watermarking as used herein refers to embedding data in an image byaltering the image in a manner that is undetectable (or almostundetectable) visually to a user. A watermarked (altered) version of anoriginal image is generated by watermarking module 114 that isindistinguishable (or almost indistinguishable) from the original imageto the human eye. Thus, a user looking at the watermarked and originalversions of the image sees very little, if any, difference between thetwo versions of the image. Although a user may not be able to discernany difference between the two versions of the image, a data extractionsystem can analyze the watermarked version of the image and readilyextract the data embedded in the watermarked version.

Programs 106 are typically pre-release or test versions of programs thatare to be kept confidential. This confidential nature of programs 106,as well as the fact that programs 106 may be tracked, is made known tousers prior to obtaining and/or running the programs. The programs 106are obtained and/or run by computing device 100 only after receivinguser acknowledgment of this confidential nature of the programs 106 andonly after receiving user consent to track programs 106. For example,the user may take an affirmative action acknowledging the confidentialnature of programs 106 and requesting that the tracking of programs 106be performed before programs 106 are obtained and/or run by computingdevice 100. After programs 106 are no longer pre-release or testversions of programs, system 108 ceases performing the screen capturewatermarking discussed herein for programs 106.

FIG. 2 illustrates an example screen capture watermarking system 200 inaccordance with one or more embodiments. System 200 can be, for example,a screen capture watermarking system 108 of FIG. 1. System 200 includesa screen capture module 202 (which can be a screen capture module 112 ofFIG. 1), a buffer 204 (which can be a buffer 104 of FIG. 1), and awatermarking module 206 (which can be a watermarking module 114 of FIG.1).

Screen capture module 202 receives or is otherwise notified of a screencapture request 210. Screen capture request 210 can be received via anyof a variety of user inputs, as discussed above. In response to screencapture request 210, screen capture module 202 obtains the buffercontent 212 from buffer 204. Module 202 can obtain the buffer content212 in various manners, such as copying the content from a locationknown to be buffer 204, invoking an application programming interface(API) or other mechanism supported by the graphics system for obtainingdata from buffer 204, and so forth. Module 202 provides the obtainedbuffer content 212 to watermarking module 206. The obtained buffercontent 212 provided to watermarking module 206 is data describing animage (an image of the screen display), which is typically an indicationof the color values for every pixel of the image. Depending on themanner in which buffer 204 is implemented, module 202 optionallyconverts the data in buffer 204 into a format that includes anindication of the color values for every pixel of the image. As buffercontent 212 includes an indication of the color values for every pixelof the image, buffer content 212 can also be referred to as an image.

Alternatively, rather than obtaining buffer content 212 from buffer 204,module 202 can send a request or otherwise inform buffer 204 to providebuffer content 212 to watermarking module 206, or module 202 can send arequest or other information to watermarking module 206 causing module206 to obtain buffer content 212 from buffer 204. In such embodiments,depending on the manner in which buffer 204 is implemented, watermarkingmodule 206 optionally converts the data in buffer 204 into a format thatincludes an indication of the color values for every pixel of the image.

Regardless of how watermarking module 206 obtains buffer content 212,module 206 obtains data 214 to embed in buffer content 212. In one ormore embodiments, data 214 includes data identifying a copy of a programrunning on the device implementing system 200 (e.g., a program 106 ofFIG. 1). Data 214 may additionally, or alternatively, includeinformation about the user of the device implementing system 200.Watermarking module 206 can obtain data 214 from a data store that canbe implemented in various manners, such as a registration data store(e.g., an operating system registry, a database, or other informationstore), a secure memory location (e.g., that can be read from but notwritten to except by a secure or trusted processor or module), and soforth. Alternatively, rather than obtaining data 214 from a data store,watermarking module 206 can retrieve data 214 from the program, cangenerate data 214 (e.g., based on the instructions of the program, basedon data returned from the program in response to a request from module206, and so forth), can retrieve data 214 from elsewhere (e.g., anothermodule or component of system 200), and so forth.

Data 214 can include various information. In one or more embodiments,different copies of programs have different identifiers. A copy of aprogram refers to the code (e.g., instructions, binaries, configurationdata, etc.) of the program obtained by a particular user or otherentity. For example, a program may be an operating system and multipleusers may download or otherwise obtain a copy of the same operatingsystem—although the operating system itself can be the same for all ofthe users that obtained a copy of the operating system, each userobtained their own copy of the operating system. Data 214 includes anidentifier that identifies a particular copy of the program. Forexample, when a program is obtained by the device implementing system200, an identifier of the obtained copy of the program is also obtained.The identifier of the copy of the program is associated with that copyof the program (e.g., included in the copy of the program), and is movedwith the program if the program were to be moved (e.g., copied orotherwise transferred) to other devices. Thus, the data identifies thecopy of the program regardless of what computing device is running theprogram.

Data 214 can alternatively or additionally include the identity of auser of the device implementing system 200. This user of the device canidentify, for example, a current user of the device and/or a user thatobtained the copy of the program on the device. The user of the devicecan be an individual or other entity, such as a company, a division of acompany, another group, and so forth. Data 214 can alternatively oradditionally include other information, such as an identifier of thedevice implementing system 200, identifiers of other programs running onthe device implementing system 200, various characteristics of thedevice implementing system 200 (e.g., an Internet protocol (IP) address,a media access control (MAC) address, etc.), and so forth. The data 214is also discussed in more detail below.

In one or more embodiments, a program (e.g., program 106 of FIG. 1) isan operating system of the computing device that implements system 200,and data 214 is an identifier of a particular copy of the operatingsystem. Other programs may be run at the same time as the operatingsystem, but data 214 includes an identifier of the copy of the operatingsystem rather than any of the other programs.

Alternatively, one or more programs (e.g., programs 106 of FIG. 1) canbe other programs run by an operating system of the computing devicethat implements system 200, and data 214 is an identifier of particularcopies of those one or more programs. The one or more programs for whichidentifiers are to be included in data 214 can be determined in variousmanners, such as being programs identified by a user of system 200,programs identified by another component or module, a currently activeprogram, a program for which a window is currently being displayed, aprogram for which a window currently being displayed is a top-levelwindow, and so forth.

Watermarking module 206 embeds data 214 in the obtained buffer content.The embedded data is very difficult for a user to detect visually, butcan be extracted by an extraction system that is aware of the techniqueused to embed the watermark. This technique can include various aspects(such as secret keys and/or methods) that make it very difficult toextract the embedded data without knowledge of these aspects. Thus, if auser were aware that data is embedded in the buffer content (e.g., dueto their consent to have the program tracked as discussed above), theuser is prevented from extracting the embedded data if the user does nothave knowledge of these various aspects because of the difficulty suchextraction would entail.

Generally, watermarking module 206 embeds data 214 in the obtainedbuffer content by making alterations or changes to the obtained buffercontent. These alterations or changes are also referred to as thewatermark. Watermarking module 206 can embed data 214 in variousmanners, such as by using statistics quantization to alter variousdifferent statistics regarding the data in the obtained screen buffercontent. The embedding of data 214 in the buffer content is discussed inmore detail below.

The buffer content altered to embed data 214 is referred to as thewatermarked buffer content 216, which is returned to screen capturemodule 202. Module 202 makes watermarked buffer content 216 available inresponse to screen capture request 210. Watermarked buffer content 216can be made available in various manners, such as by storing content 216in a particular location where screen capture content is expected (e.g.,a clipboard), returning content 216 as a return value in response torequest 210, storing content 216 in a data store (e.g., a database), andso forth.

It should be noted that, although the user can be notified that aprogram is being tracked and consent to such tracking as discussedabove, the user need not be aware of what data is being embedded in thebuffer content, how the data is being embedded in the buffer content,and/or whether watermarked buffer content is being generated. Thewatermarked buffer content is visually indistinguishable (or almostindistinguishable) from the buffer content, making it very difficult fora user to detect the presence of the watermark.

FIG. 3 illustrates another example screen capture watermarking system300 in accordance with one or more embodiments. System 300 can be, forexample, a screen capture watermarking system 108 of FIG. 1. System 300is analogous to screen capture watermarking system 200 of FIG. 2, andincludes a screen capture module 202, a buffer 204, and a watermarkingmodule 206. Buffer content 212 is obtained by screen capture module 202,data 214 is obtained by watermarking module 206, and watermarked buffercontent 216 is obtained by screen capture module 202.

System 300 differs from system 200 of FIG. 2 in that in system 300 ascreen capture request 210 is not received by screen capture module 202.Rather, screen capture module 202 obtains buffer content 212 in responseto various other criteria being satisfied. This criteria can be, forexample, an elapsed amount of time since a watermarked version of buffercontent was last generated (e.g., so that watermarked buffer content isgenerated at various intervals, such as every 10 milliseconds, every 100milliseconds, etc.), a change in the screen display (e.g., so that awatermarked version of buffer content is generated for each screendisplay), a request from another device or module to generate awatermarked version of buffer content, and so forth.

Once the criteria being used by screen capture module 202 are satisfied,buffer content 212 is obtained and watermarked buffer content 216 isgenerated as discussed above with respect to screen capture watermarkingsystem 200 of FIG. 2. Watermarked buffer content 216 is made availableby module 202 in various manners, such as by storing content 216 in aparticular location where screen capture content is expected (e.g., aclipboard), returning content 216 as a return value in response to arequest received by module 202 for watermarked buffer content, storingcontent 216 in a data store (e.g., a database), storing content 216 inbuffer 204, and so forth.

In the discussions herein, data is discussed as being embedded in buffercontent. The embedded data can include various information, andtypically includes one or both of data identifying a user of the deviceimplementing the screen capture watermarking system and data identifyinga copy of a program on the device implementing the screen capturewatermarking system. Various different identifiers can be used as dataidentifying a copy of a program on the device. In one or moreembodiments, a product key associated with the program is used as theidentifier of the program. Each copy of the program has an associatedproduct key that is used to activate the program. To activate aparticular copy of the program, the product key associated with the copyis provided to an activation service (typically over a data network,such as the Internet, a local area network, a telephone network, etc.).The activation service verifies that the provided product key is theproper product key for the copy of the program, and activates the copyof the program for running on the device only if the product key isverified. The copy of the program can be restricted in various manners(e.g., not allowed to run, allowed to run only a particular number oftimes, allowed to run with restricted functionality, and so forth) ifthe product key is not verified.

In other embodiments, a fingerprint of the copy of the program is usedas the identifier of the copy of the program. When the copy of theprogram is obtained by a computing device from an authorized source(e.g., a server or service that distributes, and that is permitted bythe developer of the program to distribute, the program), a fingerprintis included in the copy of the program. The fingerprint can be included,for example, in a known (e.g., predefined) fingerprint location of thecopy of the program. The fingerprint is generated by the authorizedsource, and includes a user portion and/or a program portion. The userportion can be generated by computing the result of a one-waycryptographic function of information identifying a user (e.g., aperson, a company, or other entity) that is obtaining the program. Byusing the one-way cryptographic function, the specific identity of theuser cannot be derived from the fingerprint. This informationidentifying the user can be, for example, information used by the userto log on to the server or service that distributes the program.

The program portion includes information about the program. Thisinformation can be, for example, a program name, a program version(e.g., build) number, a timestamp when the program was created and/orobtained, combinations thereof, and so forth. The fingerprint canoptionally be signed, such as using a private key of a public/privatekey pair of the authorized source. This signature can be subsequentlyverified using the public key of the public/private key pair, and reliedupon as an identifier of the program only if the signature issubsequently verified.

In the discussions here, data is discussed as being embedded in thebuffer content using watermarking. Although various differentwatermarking techniques can be used, the watermarking technique usedgenerally has the following characteristics. The watermarking techniqueresults in watermarked buffer content that is undetectable (or nearlyundetectable) to the human eye—when an image from the watermarked buffercontent is displayed to a user the image of the watermarked buffercontent is indistinguishable (or nearly indistinguishable) from an imagefrom the buffer content. The watermarking is thus typically notnoticeable to the user.

The watermarking technique also operates quickly, typically generatingthe watermarked buffer content in less than a threshold amount of time(e.g., less than 33 milliseconds, less than 20 milliseconds, etc.). Bygenerating the watermarked buffer content quickly, the watermarkingscreen capture content techniques discussed herein do not result innoticeable delay to the user (e.g., there is typically no delayresulting from the watermarking that is noticeable to the user inresponse to a screen capture request).

The watermarking technique also provides robustness against variouscompression algorithms. The watermarked buffer content may besubsequently compressed (e.g., in response to a user request or as partof standard image-file encoding), and the watermarking technique isresistant to such compression. By being resistant to such compression,the embedded data is more likely to be detectable after compression ofthe watermarked buffer content.

The watermarking technique is also a dynamic technique that adjustsbased on the content in which the data is being embedded. The data isembedded in portions of the buffer content having higher entropy thanother portions, resulting in the data being embedded more quickly, morerobustly, and with less likelihood of being visibly detectable due tothe higher entropy of the portions in which the data is embedded.

In one or more embodiments, the watermarking is performed based onstatistics quantization. Portions (e.g., rectangles, triangles, or othershapes), optionally overlapping, of the buffer content or of a transformthereof are selected. These portions can be selected in various manners,such as pseudorandomly or according to other rules or criteria. A keyused as a seed value for a pseudorandom number generation (which is thebasis for pseudorandomly selecting portions) can be maintained as asecret (e.g., by the watermarking module, or another module thatprovides pseudorandom numbers to the watermarking module).

Statistics regarding the selected portions are generated. Various typesof statistics can be generated, such as averages of waveletcoefficients, pixel intensities, and so forth. The statistics for one ormore of the selected portions are then adjusted or quantized to be inaccordance with a particular pattern (e.g., divisible by a particularnumber), the particular pattern indicating the value of a bit (e.g., avalue of zero or a value of one). By adjusting or quantizing thestatistics for multiple portions, multiple bit values can be embedded inthe buffer content, and the data (e.g., the different bits of the data)can be embedded in the buffer content. In one or more embodiments, thevalue of a bit is embedded in a selected portion only if the statisticsindicate at least a threshold amount of entropy in the portion (e.g., atleast a threshold average pixel intensity value, at least a thresholdaverage wavelet coefficient value, and so forth). A subset of theselected portions can also optionally be selected, the subset being anumber (e.g., equal to the number of bits in the data to be embedded) ofportions of the selected portions having higher entropy than otherportions (e.g., the portions having greater average pixel intensities,the portions having greater average wavelet coefficient values, and soforth).

The watermarked buffer content generated by a screen capturewatermarking system can later be analyzed and the data embedded in thewatermarked buffer content extracted. Thus, the copy of a program thatwas running when the screen capture occurred can be identified after thewatermarked buffer content is generated.

FIG. 4 is a block diagram illustrating an example watermark dataextraction system 400 in accordance with one or more embodiments.Watermark data extraction system 400 includes an image acquisitionmodule 402 and a data extraction module 404. Image acquisition module402 receives or otherwise obtains an image from which embedded data isto be extracted. Data extraction module 404 analyzes the obtained imageand extracts data embedded in a watermark of the image.

Data extraction module 404 can extract the data embedded in thewatermark of the image in a variety of different manners. Dataextraction module 404 has knowledge of (e.g., is programmed with orotherwise obtains) how data was embedded in the image (e.g., bywatermarking module 206 of FIG. 2 or FIG. 3 discussed above), includingknowledge of any keys, methods, and so forth used to embed the data.Given this knowledge of the manner in which data was embedded, dataextraction module 404 can readily extract the data embedded in theimage. For example, data extraction module 404 can use the samepseudorandom number generator and seed value to select portions of theimage as were used by watermarking module 206, and analyze generatedstatistics (the same type of statistics as were used by watermarkingmodule 206) to readily identify what values (if any) are embedded in theselected portions.

The extracted data can then be used to identify the particular copy ofthe program that was running when the screen capture was made (e.g.,when a screen capture request was received). A record of the user (e.g.,a person, a company, or other entity) associated with each copy of theprogram can be maintained (e.g., by the developer, authorized source ofthe program, etc.), allowing which user obtained the copy of the programrunning in the screen capture to be readily identified. By embeddingdata identifying the particular copy of the program, no record of thedevice running the program need be maintained. The copy of the programcould be run on any device, whether known to the developer (orauthorized source) or not, and which user obtained the copy of theprogram running in the screen capture is still able to be readilyidentified.

FIG. 5 is a flowchart illustrating an example process 500 forwatermarking screen capture content in accordance with one or moreembodiments. Process 500 is carried out by a screen capture watermarkingsystem, such as system 108 of FIG. 1, system 200 of FIG. 2, or system300 of FIG. 3, and can be implemented in software, firmware, hardware,or combinations thereof. Process 500 is shown as a set of acts and isnot limited to the order shown for performing the operations of thevarious acts. Process 500 is an example process for watermarking screencapture content; additional discussions of watermarking screen capturecontent are included herein with reference to different figures.

In process 500, buffer content is obtained (act 502). The buffer contentis content that describes a screen display that is to be displayed by adevice. The buffer content can be obtained by various modules indifferent manners, as discussed above.

The buffer content obtained in act 502 is watermarked (act 504). Thewatermarking can embed various data in the buffer content as discussedabove. The watermarked buffer content is a version of the buffer contentin which data is such that the data is undetectable (or nearlyundetectable) to the human eye, but can nonetheless be extracted byother computing devices or systems.

The watermarked buffer content is stored or returned (act 506). Thewatermarked buffer content can be returned to a requester that provideda request in response to which the watermarked buffer content wasgenerated, can be stored in a particular location or data store, and soforth as discussed above.

FIG. 6 is a flowchart illustrating another example process 600 forwatermarking screen capture content in accordance with one or moreembodiments. Process 600 is carried out by a screen capture watermarkingsystem, such as system 108 of FIG. 1, system 200 of FIG. 2, or system300 of FIG. 3, and can be implemented in software, firmware, hardware,or combinations thereof. Process 600 is shown as a set of acts and isnot limited to the order shown for performing the operations of thevarious acts. Process 600 is an example process for watermarking screencapture content; additional discussions of watermarking screen capturecontent are included herein with reference to different figures.

In process 600, a screen capture request is received (act 602). Thescreen capture request can be received as various different user inputs,as discussed above.

In response to receiving the screen capture request, buffer content isobtained (act 604). The buffer content is content that describes ascreen display that is to be displayed by a device. The buffer contentcan be obtained by various modules in different manners, as discussedabove.

The buffer content obtained in act 604 is watermarked (act 606). Thewatermarking can embed various data in the buffer content as discussedabove. The watermarked buffer content is a version of the buffer contentin which data is such that the data is undetectable (or nearlyundetectable) to the human eye, but can nonetheless be extracted byother computing devices or systems.

The watermarked buffer content is made available in response to thescreen capture request (act 608). The watermarked buffer content can bemade available in various manners, as discussed above. In one or moreembodiments, the watermarked buffer content is stored in a particularmemory location where screen capture data is expected (e.g., by theoperating system, by a user, etc.), and this location can vary based onthe system implementing process 600 (and/or the device which implementsthat system), desires of the designer of the system implementing process600 (and/or the device which implements that system), and so forth. Forexample, the watermarked buffer content can be stored in a clipboard ofan operating system running on the device that implements the systemimplementing process 600.

Various actions performed by various modules are discussed herein. Aparticular module discussed herein as performing an action includes thatparticular module itself performing the action, or alternatively thatparticular module invoking or otherwise accessing another component ormodule that performs the action (or performs the action in conjunctionwith that particular module). Thus, a particular module performing anaction includes that particular module itself performing the actionand/or another module invoked or otherwise accessed by that particularmodule performing the action.

Additionally, although particular functionality is discussed herein withreference to particular modules, it should be noted that thefunctionality of individual modules discussed herein can be separatedinto multiple modules, and/or at least some functionality of multiplemodules can be combined into a single module.

FIG. 7 illustrates an example system generally at 700 that includes anexample computing device 702 that is representative of one or moresystems and/or devices that may implement the various techniquesdescribed herein. The computing device 702 may be, for example, a serverof a service provider, a device associated with a client (e.g., a clientdevice), an on-chip system, and/or any other suitable computing deviceor computing system.

The example computing device 702 as illustrated includes a processingsystem 704, one or more computer-readable media 706, and one or more I/OInterfaces 708 that are communicatively coupled, one to another.Although not shown, the computing device 702 may further include asystem bus or other data and command transfer system that couples thevarious components, one to another. A system bus can include any one orcombination of different bus structures, such as a memory bus or memorycontroller, a peripheral bus, a universal serial bus, and/or a processoror local bus that utilizes any of a variety of bus architectures. Avariety of other examples are also contemplated, such as control anddata lines.

The processing system 704 is representative of functionality to performone or more operations using hardware. Accordingly, the processingsystem 704 is illustrated as including hardware elements 710 that may beconfigured as processors, functional blocks, and so forth. This mayinclude implementation in hardware as an application specific integratedcircuit or other logic device formed using one or more semiconductors.The hardware elements 710 are not limited by the materials from whichthey are formed or the processing mechanisms employed therein. Forexample, processors may be comprised of semiconductor(s) and/ortransistors (e.g., electronic integrated circuits (ICs)). In such acontext, processor-executable instructions may beelectronically-executable instructions.

The computer-readable media 706 is illustrated as includingmemory/storage 712. The memory/storage 712 represents memory/storagecapacity associated with one or more computer-readable media. Thememory/storage 712 may include volatile media (such as random accessmemory (RAM)) and/or nonvolatile media (such as read only memory (ROM),Flash memory, optical disks, magnetic disks, and so forth). Thememory/storage 712 may include fixed media (e.g., RAM, ROM, a fixed harddrive, and so on) as well as removable media (e.g., Flash memory, aremovable hard drive, an optical disc, and so forth). Thecomputer-readable media 706 may be configured in a variety of other waysas further described below.

Input/output interface(s) 708 are representative of functionality toallow a user to enter commands and information to computing device 702,and also allow information to be presented to the user and/or othercomponents or devices using various input/output devices. Examples ofinput devices include a keyboard, a cursor control device (e.g., amouse), a microphone (e.g., for voice inputs), a scanner, touchfunctionality (e.g., capacitive or other sensors that are configured todetect physical touch), a camera (e.g., which may employ visible ornon-visible wavelengths such as infrared frequencies to detect movementthat does not involve touch as gestures), and so forth. Examples ofoutput devices include a display device (e.g., a monitor or projector),speakers, a printer, a network card, tactile-response device, and soforth. Thus, the computing device 702 may be configured in a variety ofways as further described below to support user interaction.

Computing device 702 also includes a screen capture watermarking system714. Screen capture watermarking system 714 provides variousfunctionality for watermarking buffer content for screen captures, asdiscussed above. Screen capture watermarking system 714 can implement,for example, screen capture watermarking system 108 of FIG. 1, screencapture watermarking system 200 of FIG. 2, and/or screen capturewatermarking system 300 of FIG. 3. Alternatively, rather than screencapture watermarking system 714, computing device 702 can include awatermark data extraction system such as watermark data extractionsystem 400 of FIG. 4.

Various techniques may be described herein in the general context ofsoftware, hardware elements, or program modules. Generally, such modulesinclude routines, programs, objects, elements, components, datastructures, and so forth that perform particular tasks or implementparticular abstract data types. The terms “module,” “functionality,” and“component” as used herein generally represent software, firmware,hardware, or a combination thereof. The features of the techniquesdescribed herein are platform-independent, meaning that the techniquesmay be implemented on a variety of computing platforms having a varietyof processors.

An implementation of the described modules and techniques may be storedon or transmitted across some form of computer-readable media. Thecomputer-readable media may include a variety of media that may beaccessed by the computing device 702. By way of example, and notlimitation, computer-readable media may include “computer-readablestorage media” and “computer-readable signal media.”

“Computer-readable storage media” refers to media and/or devices thatenable persistent storage of information and/or storage that istangible, in contrast to mere signal transmission, carrier waves, orsignals per se. Thus, computer-readable storage media refers tonon-signal bearing media. The computer-readable storage media includeshardware such as volatile and non-volatile, removable and non-removablemedia and/or storage devices implemented in a method or technologysuitable for storage of information such as computer readableinstructions, data structures, program modules, logic elements/circuits,or other data. Examples of computer-readable storage media may include,but are not limited to, RAM, ROM, EEPROM, flash memory or other memorytechnology, CD-ROM, digital versatile disks (DVD) or other opticalstorage, hard disks, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or other storage device,tangible media, or article of manufacture suitable to store the desiredinformation and which may be accessed by a computer.

“Computer-readable signal media” refers to a signal-bearing medium thatis configured to transmit instructions to the hardware of the computingdevice 702, such as via a network. Signal media typically may embodycomputer readable instructions, data structures, program modules, orother data in a modulated data signal, such as carrier waves, datasignals, or other transport mechanism. Signal media also include anyinformation delivery media. The term “modulated data signal” means asignal that has one or more of its characteristics set or changed insuch a manner as to encode information in the signal. By way of example,and not limitation, communication media include wired media such as awired network or direct-wired connection, and wireless media such asacoustic, RF, infrared, and other wireless media.

As previously described, hardware elements 710 and computer-readablemedia 706 are representative of instructions, modules, programmabledevice logic and/or fixed device logic implemented in a hardware formthat may be employed in some embodiments to implement at least someaspects of the techniques described herein. Hardware elements mayinclude components of an integrated circuit or on-chip system, anapplication-specific integrated circuit (ASIC), a field-programmablegate array (FPGA), a complex programmable logic device (CPLD), and otherimplementations in silicon or other hardware devices. In this context, ahardware element may operate as a processing device that performsprogram tasks defined by instructions, modules, and/or logic embodied bythe hardware element as well as a hardware device utilized to storeinstructions for execution, e.g., the computer-readable storage mediadescribed previously.

Combinations of the foregoing may also be employed to implement varioustechniques and modules described herein. Accordingly, software,hardware, or program modules and other program modules may beimplemented as one or more instructions and/or logic embodied on someform of computer-readable storage media and/or by one or more hardwareelements 710. The computing device 702 may be configured to implementparticular instructions and/or functions corresponding to the softwareand/or hardware modules. Accordingly, implementation of modules as amodule that is executable by the computing device 702 as software may beachieved at least partially in hardware, e.g., through use ofcomputer-readable storage media and/or hardware elements 710 of theprocessing system. The instructions and/or functions may beexecutable/operable by one or more articles of manufacture (for example,one or more computing devices 702 and/or processing systems 704) toimplement techniques, modules, and examples described herein.

As further illustrated in FIG. 7, the example system 700 enablesubiquitous environments for a seamless user experience when runningapplications on a personal computer (PC), a television device, and/or amobile device. Services and applications run substantially similar inall three environments for a common user experience when transitioningfrom one device to the next while utilizing an application, playing avideo game, watching a video, and so on.

In the example system 700, multiple devices are interconnected through acentral computing device. The central computing device may be local tothe multiple devices or may be located remotely from the multipledevices. In one or more embodiments, the central computing device may bea cloud of one or more server computers that are connected to themultiple devices through a network, the Internet, or other datacommunication link.

In one or more embodiments, this interconnection architecture enablesfunctionality to be delivered across multiple devices to provide acommon and seamless experience to a user of the multiple devices. Eachof the multiple devices may have different physical requirements andcapabilities, and the central computing device uses a platform to enablethe delivery of an experience to the device that is both tailored to thedevice and yet common to all devices. In one or more embodiments, aclass of target devices is created and experiences are tailored to thegeneric class of devices. A class of devices may be defined by physicalfeatures, types of usage, or other common characteristics of thedevices.

In various implementations, the computing device 702 may assume avariety of different configurations, such as for computer 716, mobile718, and television 720 uses. Each of these configurations includesdevices that may have generally different constructs and capabilities,and thus the computing device 702 may be configured according to one ormore of the different device classes. For instance, the computing device702 may be implemented as the computer 716 class of a device thatincludes a personal computer, desktop computer, a multi-screen computer,laptop computer, netbook, and so on.

The computing device 702 may also be implemented as the mobile 718 classof device that includes mobile devices, such as a mobile phone, portablemusic player, portable gaming device, a tablet computer, a multi-screencomputer, and so on. The computing device 702 may also be implemented asthe television 720 class of device that includes devices having orconnected to generally larger screens in casual viewing environments.These devices include televisions, set-top boxes, gaming consoles, andso on.

The techniques described herein may be supported by these variousconfigurations of the computing device 702 and are not limited to thespecific examples of the techniques described herein. This functionalitymay also be implemented all or in part through use of a distributedsystem, such as over a “cloud” 722 via a platform 724 as describedbelow.

The cloud 722 includes and/or is representative of a platform 724 forresources 726. The platform 724 abstracts underlying functionality ofhardware (e.g., servers) and software resources of the cloud 722. Theresources 726 may include applications and/or data that can be utilizedwhile computer processing is executed on servers that are remote fromthe computing device 702. Resources 726 can also include servicesprovided over the Internet and/or through a subscriber network, such asa cellular or Wi-Fi network.

The platform 724 may abstract resources and functions to connect thecomputing device 702 with other computing devices. The platform 724 mayalso serve to abstract scaling of resources to provide a correspondinglevel of scale to encountered demand for the resources 726 that areimplemented via the platform 724. Accordingly, in an interconnecteddevice embodiment, implementation of functionality described herein maybe distributed throughout the system 700. For example, the functionalitymay be implemented in part on the computing device 702 as well as viathe platform 724 that abstracts the functionality of the cloud 722.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

What is claimed is:
 1. One or more computer-readable storage mediahaving stored thereon multiple instructions that, when executed by oneor more processors of a computing device, cause the one or moreprocessors to: obtain content of a graphics buffer of the computingdevice, the content of the graphics buffer describing a screen displayat a particular time; watermark the content of the graphics buffer withdata identifying a copy of a program running on the computing device;and store the watermarked content of the graphics buffer.
 2. One or morecomputer-readable storage media as recited in claim 1, the datacomprising data identifying the copy of the program running on thecomputing device, the program comprising an operating system of thecomputing device.
 3. One or more computer-readable storage media asrecited in claim 1, the instructions causing the one or more processorsto watermark the content of the graphics buffer comprising instructionscausing the one or more processors to alter the content of the graphicsbuffer in a manner to embed the data so that the data is visuallyundetectable.
 4. One or more computer-readable storage media as recitedin claim 1, the data comprising a product key that can activate the copyof the program.
 5. One or more computer-readable storage media asrecited in claim 1, the instructions causing the one or more processorsto watermark the content of the graphics buffer further causing the oneor more processors to watermark the content of the graphics buffer withdata identifying the computing device.
 6. One or more computer-readablestorage media as recited in claim 1, the instructions causing the one ormore processors to store the watermarked content of the graphics buffercomprising instructions causing the one or more processors to store thewatermarked content of the graphics buffer in the graphics buffer. 7.One or more computer-readable storage media as recited in claim 1, theinstructions causing the one or more processors to store the watermarkedcontent of the graphics buffer comprising instructions causing the oneor more processors to store the watermarked content of the graphicsbuffer in a memory location where screen capture data is expected. 8.One or more computer-readable storage media as recited in claim 1, theinstructions causing the one or more processors to watermark the contentof the graphics buffer comprising instructions causing the one or moreprocessors to watermark the graphics buffer content without a user ofthe computing device being aware of the watermarking.
 9. One or morecomputer-readable storage media as recited in claim 1, the instructionscausing the one or more processors to watermark the content of thegraphics buffer comprising instructions causing the one or moreprocessors to watermark the graphics buffer content by embedding thedata in the graphics buffer content in a manner preventing extracting ofthe embedded data without knowledge of one or more aspects used to embedthe data.
 10. One or more computer-readable storage media as recited inclaim 1, the instructions causing the one or more processors towatermark the content comprising instructions causing the one or moreprocessors to watermark the graphics buffer content in a dynamic mannerbased on data in the graphics buffer content by embedding the dataidentifying the program in portions of the graphics buffer contenthaving higher entropy than other portions of the graphics buffercontent.
 11. A method comprising: receiving, at a device, a screencapture request; retrieving, in response to the screen capture request,content of a graphics buffer of the device, the content of the graphicsbuffer describing a screen display at a particular time; watermarking,with data identifying a copy of a program running on the device, thecontent of the graphics buffer; and making the watermarked content ofthe graphics buffer available in response to the screen capture request.12. A method as recited in claim 11, the data comprising dataidentifying the copy of the program running on the device, and theprogram comprising an operating system of the device.
 13. A method asrecited in claim 11, the watermarking comprising altering the content ofthe graphics buffer in a manner to embed the data so that the data isvisually undetectable.
 14. A method as recited in claim 11, the datacomprising a product key that can activate the copy of the program. 15.A method as recited in claim 11, the watermarking further comprisingwatermarking the content of the graphics buffer with data identifyingthe device.
 16. A method as recited in claim 11, the making thewatermarked content of the graphics buffer available comprising storingthe watermarked content of the graphics buffer in the graphics buffer.17. A method as recited in claim 11, the making the watermarked contentof the graphics buffer available comprising storing the watermarkedcontent of the graphics buffer in a memory location where screen capturedata is expected.
 18. A method as recited in claim 11, the watermarkingcomprising watermarking the graphics buffer content by embedding thedata in the content of the graphics buffer in a manner preventingextracting of the embedded data without knowledge of one or more aspectsused to embed the data.
 19. A method as recited in claim 11, thewatermarking comprising watermarking the graphics buffer content in adynamic manner based on data in the graphics buffer content by embeddingthe data identifying the program in portions of the graphics buffercontent having higher entropy than other portions of the graphics buffercontent.
 20. A device comprising: a graphics buffer having contentdescribing a screen display of the device at a particular time; a screencapture module configured to receive a screen capture request, andobtain, in response to the screen capture request, the graphics buffercontent from the graphics buffer; a watermarking module configured toobtain the graphics buffer content from the screen capture module, andwatermark the content of the graphics buffer with data by altering thecontent of the graphics buffer in a manner to embed the data so that thedata is visually undetectable, the data identifying a copy of anoperating system of the device; and the screen capture module beingfurther configured to make the watermarked content of the graphicsbuffer available in response to the screen capture request.
 21. A methodcomprising: retrieving content of a graphics buffer of a device, thecontent of the graphics buffer describing a screen display at aparticular time; watermarking, with data identifying a copy of a programrunning on the device, the content of the graphics buffer; and makingthe watermarked content of the graphics buffer available.
 22. A methodas recited in claim 21, the data being obtained from one or more of aregistration data store, a secure memory location, information retrievedfrom the program, information generated based on instructions of theprogram, or information returned from the program in response to arequest.
 23. A method as recited in claim 21, the data comprising afingerprint of the copy of the program used as the identifier of thecopy of the program, the fingerprint including one or both of a userportion and a program portion, wherein the user portion includesinformation identifying a user and the program portion includesinformation about the program.
 24. A device comprising: a graphicsbuffer having content describing a screen display of the device at aparticular time; a screen capture module configured to obtain thegraphics buffer content from the graphics buffer; a watermarking moduleconfigured to obtain the graphics buffer content from the screen capturemodule, and watermark the content of the graphics buffer with data byaltering the content of the graphics buffer in a manner to embed thedata so that the data is visually undetectable, the data identifying acopy of an operating system of the device; and the screen capture modulebeing further configured to make the watermarked content of the graphicsbuffer available.
 25. A device as recited in claim 24, the data furthercomprising a product key that can activate the copy of the operatingsystem.
 26. A device as recited in claim 24, the watermarking modulebeing further configured to watermark the graphics buffer content byembedding the data in the graphics buffer content in a manner preventingextracting of the embedded data without knowledge of one or more aspectsused to embed the data.
 27. A device as recited in claim 24, thewatermarking module being further configured to watermark the graphicsbuffer content by embedding the data identifying the program in portionsof the graphics buffer content having higher entropy than other portionsof the graphics buffer content.
 28. A first device comprising: an imageacquisition module configured to obtain an image from which dataembedded in a watermark is to be extracted, the image having beengenerated by watermarking, with data identifying a copy of a programrunning on a second device at a particular time, the content of agraphics buffer of the second device describing a screen display at theparticular time; and a data extraction module configured to analyze theobtained image and extract the data embedded in the watermark of theimage.
 29. A first device as recited in claim 28, the program comprisingan operating system of the second device.
 30. A first device as recitedin claim 28, the data extraction module including knowledge of one ormore aspects used to embed the data in the watermark, the knowledge ofthe one or more aspects including a pseudorandom number generator andseed value to select portions of the image used by the watermarkingeffective to identify the data embedded in the selected portions.
 31. Afirst device as recited in claim 28, the data extraction module beingfurther configured to identify the copy of the program that was runningon the second device when a screen capture occurred.